%!TEX root = main.tex
\section{Introduction}
NDNS\cite{afanasyev2013addressing,shock:ndns} is designed to be universal data storage in NDNS,
which allows authorized identity store content with any format or any size.
Since NDN adopts mutable data model, it is also possible for authorized identity to store historical data in NDNS.
what is more,
it is possible that the content to be stored, together with other field, such as Name, MetaInfo and signature,
 outsizes the upper bound of one NDN Data packet.
 
In this report, we propose a mechanism which allows NDNS to store
1) historical data with version component; and/or
2) arbitrarily large content by segmenting large content into multiple Data packets

\section{Naming Extension}
The naming is shown in Table \ref{tab:nameextensionconv}. And Figure \ref{fig:nameextensionsexample} shows an example.
\begin{table}[H]
  \begin{center}
    \caption{NDNS Naming Convention}\label{tab:nameextensionconv}
    \begin{tabular}{lllll}
      \toprule[1.5pt]
      & Name Component & Data Type \\
      \midrule[1pt]
      NDNS Name ::= & (1) Zone Name & NDN Name\cite{ndnfmt:name} \\
      & (2) Application Tag & NameComponent\cite{ndnfmt:name} \\
      & (3) Label & NDN Name\\
      & (4) Type & NameComponent \\
      & (5) Version Number? & NameComponent \\
      & (6) Segment Number? & NameComponent \\
      \bottomrule[1.5pt]
    \end{tabular}
  \end{center}
\end{table}

\begin{figure}[H]
  \begin{center}
    \includegraphics[width=5.5in]{figures/ndns-naming-extensions.pdf}
    \caption{NDNS Naming with Version and Segment Extensions}
    \label{fig:nameextensionsexample}
  \end{center}
\end{figure}

As we can see, version and segment numbers are defined as optional component in the name,
besides the four components which already defined in previous work (in fact, version number is also defined previously).
The naming scheme can be used for NDNS Query, NDNS Response.

When a Query does not contain version number, it intents to get the latest version.
When a Query does not contain segment number, it intents to get the Data without segment number, or the first segment if the content is segmented.

Note that the version component and segment component in NDNS is identified by the marker defined in NDN naming convention \cite{naming2014}.
Versioning marker is hex octet ``0xFD''.
And there are two kinds of segmenting marker. One is ``0x00'' for segment number based segmenting,
and the other is ``0xFB'' for byte offset segment number.

\section{Database}
The scheme of table rrsets in database is updated by adding three new columns, segment, is\_first\_segment, is\_latest\_version.
\begin{table}[H]
\caption{Table Rrsets Scheme} \label{tab:rrsets}
\begin{center}
\begin{tabular}{lcll}
\toprule[1.5pt]
Column & Data Type & Meaning & Constraint \\
\midrule[1pt]
id & uint64 & identifier of each row & primary key\\
zone\_id & uint64 & foreign key to Table Zones & cannot be null\\
label & blob & label of name & cannot be null\\
type & blob & type of rrset, for example, ID-CERT & cannot be null\\
version & blob & version of this record & can be null\\
is\_latest\_verion & boolean & is this the latest version & cannot be null \\
segment & blob & segment number of this Data & can be null\\
is\_first\_segment & boolean & is this the first segment & cannot be null\\
ttl &unsigned int & TTL of this record & can be null\\
data & blob & the wired format of Data packet & can be null\\
\bottomrule[1.5pt]
\end{tabular}
\end{center}
\end{table}%

Segment column is used to store segment number. The two boolean columns, is\_first\_segment and is\_latest\_version are used two indicating the first segment and latest version
in order to serve the query without version or segment numbers.

Technical wise, the two boolean columns can be omitted by ordering the version and segment column when lookup the table.
But this manner requires more complicated queries and costs more computation.
Given that segment and version fields store wire format of the corresponding name components,
we believe add two boolean column is a better design.

\section{Handle Query}
The basic query process does not change but with two new query conditions,
version (or is\_latest\_version) and segment (or is\_first\_segment).
For a specific query, if it contains version and/or segment number,
name server would try to select entry with given segment number and/or version number;
otherwise, name server would select the first segment and/or the last version.

\section{Handle Update}
%Larger content is segmented to multiple packets and embedded in multiple Interest.
The processing that name server handles Update changes a little bit in order to allow multiple version of Data:
\begin{itemize}
\item allow embedded Response contain any version number, instead of only latest version; 
\item take new parameters, version and segment into consideration, and mark RR with the latest version and/or first segment).
\item prevent NDNS-RESP Response being replaced by another NDNS-RESP Response with same name but different content. But it can be replaced by a NDNS-NACK Response with same name, and so can NDNS-NACK by a NDNS-RESP.
\end{itemize}

If a content is segment to multiple Data packets.
those Update messages are NOT handled atomically by name servers.
But authorized client could implement atomical operation on application level if it is necessary.

What's more, if a group of Update messages, embedding different segments of RR, are received by different name servers,
the name server synchronization process should end up with all name servers storing all segments.

\subsection{Remove RR}
In order to remove a specific RR at name servers,
authorized application sends an Update message embedding an NDNS-NACK Response.
Here we do not design a implicit remove command for simplicity,
by keeping Update message format and processing procedure unified.

\subsection{Vulnerability: Replay Attack}
Update message could be resent by malicious guy to fool NDNS.
However, the Update message, embedding a legal historical Response, can only interfere the RR with the same name.

Another scenario is that malicious guy fetches a NDNS-NACK generated by name server before authorized identity stores the legal Response.
Then malicious guy wraps the name server generated NDNS-NACK Response in Update, and sends it to replace Response generated by authorized identity.
This vulnerability could be prevented by checking the certificate of NDNS-NACK embedded in Update.

A way to prevent the potential replay attack is to append an ``Update Sequence Number'' in the name of Update message,
sign the entire Update message (not only the embedded NDNS Response),
and enable name servers to keep track of the sequence number.
Due to the complex mechanism and limited affected RR, we choose not to enable it, at least for now.

\subsection{Name Server Synchronization Based Update}
Name server synchronization allows any member of a broadcast group signal other member any update,
as described in ``Name Servers Synchronization in NDNS'',

In this case, authorized identity joins a broadcast group,
and could signal name servers to fetch latest RRs.
But the authorized identity itself do not have to fetch update from ``real'' name servers.
This approach has some pre-conditions:
1) The authorized identity is also authorized to join name server synchronization broadcast group.
2) The authorized identity is routable via the destination zone name, at least with the help of LINK object.